home *** CD-ROM | disk | FTP | other *** search
/ C/C++ Users Group Library 1996 July / C-C++ Users Group Library July 1996.iso / vol_300 / 332_02 / stone.c < prev    next >
C/C++ Source or Header  |  1990-03-28  |  29KB  |  1,058 lines
  1. /*----------------------------------------------------*- Fundamental -*-
  2.  
  3. Facility:        stone(6)
  4.  
  5. File:            stone.c
  6.  
  7. Associated files:    - (none)
  8.  
  9. Description:        Plays the game of Kalah.
  10.  
  11. Notes:            This program was originally available in two
  12.             versions, one for dumb terminals and ttys
  13.             (stone) and one for H19-type terminals
  14.             (hstone).  The present version is a cleaned-
  15.             up implementation of hstone, adapted for a
  16.             curses-compatible terminal interface.
  17.  
  18.             The program will only work on terminals with
  19.             at least 80 chars per line, and with at least
  20.             24 lines.  The only reason for this limit
  21.             is the screen layout - see printb()
  22.  
  23. Portability:        Edited to conform to X/Open Portability
  24.             Guide, ed. 3
  25.  
  26. Authors:        Terry Hayes & Clark Baker
  27.             Real-Time Systems Group
  28.             MIT Lab for Computer Science
  29.  
  30. Editor:            Leor Zolman
  31.  
  32.             Anders Thulin
  33.             Rydsvagen 288
  34.             S-582 50 Linkoping
  35.             SWEDEN
  36.  
  37. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
  38.  
  39. Edit history :
  40.  
  41. Vers  Ed   Date           By               Comments
  42. ----  ---  ----------  ----------------  -------------------------------
  43.  1.0    0  19xx-xx-xx  Hayes & Baker
  44.  1.1    1  19xx-xx-xx  Leor Zolman
  45.  1.2    2  1990-03-25  Anders Thulin
  46.  
  47. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
  48.  
  49. /*---  Configuration options:  ----------------------------------------
  50.  
  51. System configuration options:
  52. =============================
  53.  
  54.   ANSI        ANSI C
  55.   BSD        BSD Unix, SunOS 3.5
  56.   SV2        AT&T UNIX System V.2
  57.   XPG3        X/Open Portability Guide, ed. 3
  58.  
  59. If you have an ANSI C conformant compiler, define ANSI.  If not, choose
  60. the definition that most closely matches your environment.
  61.  
  62.  
  63. Program configuration options:
  64. ==============================
  65.  
  66.   TRACE        This definition should not be changed. It is used to
  67.         remove all code that in the original version wrote
  68.         tracing information to the screen. As these completely
  69.         destroy the screen layout they have been removed.
  70.  
  71.         A good way of including them in the program would be to
  72.         change them to write to a special trace window. This is
  73.         left as an exercise for the reader.
  74.  
  75.   BEEP        See 'comments' below
  76.  
  77.   FUDGE (65)    Used to determine the total number of game tree nodes
  78.         (game positions) to be examined -- computed as
  79.  
  80.           FUDGE * chosen level of difficulty
  81.  
  82.   MAX_LEVEL (1000)
  83.  
  84.         The maximum level of difficulty allowed. FUDGE * MAX_LEVEL
  85.         should not be larger than INT_MAX.
  86.  
  87. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
  88.  
  89. #define    ANSI    1
  90. #define    BSD    0
  91. #define    SV2    0
  92. #define    XPG3    0
  93.  
  94. #define    TRACE    0    
  95. #define    BEEP()        beep()
  96.  
  97. #define    FUDGE        32
  98. #define    MAX_LEVEL    1000
  99.  
  100. /* - - end of configuration options - - - - - - - - - - - - - - - - - - - */
  101.  
  102. #if ANSI
  103. # include <ctype.h>
  104. # include <curses.h>
  105. # include <stdio.h>
  106. # include <stdlib.h>
  107.  extern int getopt(int argc, char *argv[], char optstring[]);
  108.  extern int optind;
  109. #endif
  110.  
  111. #if BSD
  112. # include <ctype.h>
  113. # include <curses.h>
  114. # include <stdio.h>
  115.  extern int getopt();
  116.  extern int optind;
  117. #endif
  118.  
  119. #if SV2
  120. # include <ctype.h>
  121. # include <curses.h>
  122. # include <stdio.h>
  123.  extern int getopt();
  124.  extern int optind;
  125. #endif
  126.  
  127. #if XPG3
  128. # include <ctype.h>
  129. # include <curses.h>
  130. # include <stdio.h>
  131. # include <stdlib.h>
  132.  extern int getopt();
  133.  extern int optind;
  134. #endif
  135.  
  136. /*--- Comments on known problems: ------------------------------------------
  137.  
  138. curses
  139.  
  140.   Some older implementation of curses does not have the beep()
  141.   function, which beeps at the user.
  142.  
  143.   On such systems, you may need to define BEEP to produce a
  144.   beep in some other way, like fputc(0x07, stderr).
  145.  
  146.   If you cannot beep at all, try to flash the screen.
  147.  
  148.   If you cannot do either, just define BEEP to be empty, which is
  149.   permitted behaviour for curses' beep().
  150.  
  151. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*/
  152.  
  153. /*--- Original notes on the program:  -----------------------------------
  154.  
  155. "STONE"
  156. (otherwise known as "Awari")
  157.  
  158. This version written by
  159.     Terry Hayes & Clark Baker
  160.     Real-Time Systems Group
  161.     MIT Lab for Computer Science
  162. (and hacked up a little by Leor Zolman)
  163.  
  164. The algorithm used for STONE is a common one to Artificial Intelligence
  165. people: the "Alpha-Beta" pruning heuristic. By searching up and down a tree
  166. of possible moves and keeping record of the minimum and maximum scores from
  167. the terminal static evaluations, it becomes possible to pinpoint move
  168. variations which can in no way affect the outcome of the search.  Thus,
  169. those variations can be simply discarded, saving expensive static evaluation
  170. time. 
  171.  
  172. #if TRACE
  173.  
  174. To have the program print out some search statistics for every move
  175. evaluation, type the command as
  176.  
  177.   A> stone -d
  178.  
  179. To also see a move-by-move trace of each terminal evaluation, type
  180.  
  181.   A> stones -a
  182.  
  183. #end 
  184.  
  185. THIS is the kind of program that lets C show its stuff; Powerful expression
  186. operators and recursion combine to let a powerful algorithm be implemented
  187. painlessly. 
  188.  
  189. And it's fun to play!
  190.  
  191. Rules of the game:
  192.  
  193. Each player has six pits in front of him and a "home" pit on one side (the
  194. computer's home pit is on the left; your home pit is on the right.)
  195.  
  196. At the start of the game, all pits except the home pits are filled with n
  197. stones, where n can be anything from 1 to 6. 
  198.  
  199. To make a move, a player picks one of the six pits on his side of the board
  200. that has stones in it, and redistributes the stones one-by-one going
  201. counter-clockwise around the board, starting with the pit following the one
  202. picked.  The opponent's HOME pit is never deposited into. 
  203.  
  204. If the LAST stone happens to fall in that player's home pit, he moves again. 
  205.  
  206. If the LAST stone falls into an empty pit on the moving player's side of
  207. board, then any stones in the pit OPPOSITE to that go into the moving
  208. player's home pit. 
  209.  
  210. When either player clears the six pits on his side of the board, the game is
  211. over.  The other player takes all stones in his six pits and places them in
  212. his home pit.  Then, the player with the most stones in his home pit is the
  213. winner. 
  214.  
  215. The six pits on the human side are numbered one to six from left to right;
  216. the six pits on the computer's side are numbered one to six right-to-left. 
  217.  
  218. The standard game seems to be with three stones; less stones make it
  219. somewhat easier (for both you AND the computer), while more stones
  220. complicate the game.  As far as difficulty goes, well...it USED to be on a
  221. scale of 1 to 50, but I couldn't win it at level 1.  So I changed it to
  222. 1-300, and couldn't win at level 1.  So I changed it to 1-1000, and if I
  223. STILL can't win it at level 1, I think I'm gonna commit suicide. 
  224.  
  225. Good Luck!!!
  226.  
  227. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  228.  
  229. Notes added by Anders Thulin:
  230.  
  231. The present program plays the game of Kalah.  It does not play the game of
  232. Oware, which has slightly more complicated rules.  For a description of
  233. Oware (as well as other games of the Mancala family), take a look at Ian
  234. Lennox-Smith's series of articles in the British magazine Games & Puzzles,
  235. no. 26-29 (July-October 1974), or any reliable book on board games (there
  236. *are* unreliable ones!)
  237.  
  238. Kalah is usually played with 3-6 stones in each pit. The game with only one
  239. stone in each pit is 'trivial' (won by the first player), as well as that
  240. with two stones. It is reasonably easy to modify this program to check this
  241. statement out. 
  242.  
  243. There is an interesting paper on a learning implementation of Kalah in
  244. Machine Intelligence vol. 3, ed. D. Michie, Edinburgh 1974. The paper is
  245. written by A. G. Bell; the title is 'Kalah on Atlas'.
  246.  
  247. For a description of the alpha-beta pruning algorithm, see almost any
  248. introductory work on artificial intelligence. A good description is given by
  249. David Levy in The Chess Computer Handbook, Batsford, London 1984.
  250.  
  251. For an interesting description of different minimax algorithms (including
  252. the alpha-beta algorithm) see the article 'A Comparison of Minimax Tree
  253. Search Algorithms' by Murray S. Campbell and T.A. Marsland i